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Filed: October 24, 2003 Art Unit: 2454 

For: ADAPTING A USER INTERFACE ON A Examiner: Vu, Viet Duy 

DISPLAY DEVICE OF A PROTOCOL 
TESTER 


REPLY BRIEF 

MS Appeal Brief - Patents 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

Dear Sir: 

In connection with the appeal of the Examiner's final rejection of the above-identified 
application, Appellant submits the following comments in response to the Examiner's 
Answer dated September 18, 2009. 

A. Claim elements at issue in Appeal 

Claims 1, 2, 4 - 10, and 12-21 are pending in the application and have been finally 
rejected as unpatentable under 35 U.S.C. § 103(a) as being obvious based on U.S. Patent 
Publication No. 2003/0225876 to Oliver, et al (hereinafter "Oliver"). 

The claims on appeal are claims 1, 2, 4 - 10, 12 - 16, 20 and 21. Independent claim 1 
was previously amended to incorporate the elements of claims 3 and 11, which have been 
canceled. (Amendment dated August 21, 2008). Claims 2, 4-10, and 12-16 depend from 
independent claim 1. Claims 20-21 depend from independent claim 17. Should claim 20 or 
claim 21 be found allowable, Appellant will re-write those claims in independent form. 

In view of Appellant's and the Examiner's remarks in the filings beginning with the 
Final Office Action dated October 24, 2008, it appears that the dispute over the current 
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rejection is focused on the following claim elements: 

In independent Claim 1 : 

modifying the visual network plan on the display device in 
comparison to a basic network plan according to which hardware and/or 
software exists in the protocol tester ; 

wherein the text file only defines the position and connections of 
elements of the visual network plan while an interpreter marks the 
elements for which a selection exists and/or which may be used for the 
configuration of the telecommunication measurement task according to 
the hardware and/or software of the protocol tester . 

In dependent claim 20: 

identifying one or more software application stored on the 
measurement device . 

In dependent claim 21: 

identifying one or more hardware components installed on the 
measurement device . 

In particular, Appellant submits that the Oliver reference does not teach or suggest 
modifying or marking a visual network plan according to the hardware or software on a 
protocol tester and does not identify software or hardware on a measuring device. 

B. Differences between the Oliver reference and the pending claims 
1. Modifying the visual network plan 

Claim 1 recites: 

modifying the visual network plan on the display device in 
comparison to a basic network plan according to which hardware and/or 
software exists in the protocol tester; 

The Examiner has cited paragraphs [0028]-[0029] and [0054]-[0055] in Oliver as 
disclosing this element. (Examiner's Answer at 4). These paragraphs are copied below. 

[0028] In step 160 [of FIG. 1], the performance monitor displays the 
network. Network elements within the network may be depicted as smart 
icons with interconnections to other smart icons. The smart icons may be 
partially or entirely colored according to a performance metric of interest. 
For example, the network may be rendered based on the network map. 
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Then, the user may select a performance metric for display. The 
performance monitor will then color the smart icon for each network 
element with the appropriate color based on the level of performance for 
the selected performance metric for that network element Thus, the user 
will be shown a graphic depiction of the network with color highlighting 
the performance of the overall network. The performance monitor will 
update with color associated with the smart icons representing the 
network elements in real time as the performance metrics are updated 
periodically over the published message bus. 

[0029] In addition, the user may show the same network map using 
different performance metrics to color the smart icons representing the 
network elements one at a time. Alternatively, the user may "drill" down 
on parts of the network to see more specific information. When the 
network map is hierarchical, the performance map may display 
subsections of the network that are selected. Each subsection has its own 
"view" which provides more detail about that part of the network. When 
this is done, the smart icons in the lower level view will also be colored 
according to the color scheme of the selected performance metric. 

[0054] FIG. 8 depicts a method of monitoring the performance of the 
network according to an embodiment of the present invention. Referring 
to FIG. 8, in step 800, the performance monitor reads and displays the 
network view chosen by the user. In step 805, the performance monitor 
reads the performance queue and in step 810 stores in a buffer 
performance metric information for the network. In step 815, the 
performance monitor determines which metric to display based on input 
from the user or other criteria. The user input may be provided through a 
menuing structure which displays available metrics for the user to choose. 
Alternatively, the polling monitor may cycle through the performance 
metrics one at a time or may be set to a default value for a particular 
network view. 

[0055] In step 820, the performance monitor displays a color as part 
of an icon associated with a hierarchical object depicted in the network 
view. The hierarchical object may be a network element, link or a subnet 
or network or network elements. When the object is a network element or 
link, the color may be selected based on the selected performance metric 
for that network element. When the object is a subnet or hierarchical 
depiction of multiple network elements or interfaces, the color may be 
chosen to represent the worst case element or interface within the object. 
Any other convenient coloring scheme is contemplated, however, for 
hierarchical objects including averaging the performance metric data for 
network elements or interfaces within the object or depicting the best 
performing element or interface. Combinations of different performance 
metrics are also contemplated to determine the coloring. 

In view of this disclosure, Oliver teaches displaying network elements as smart icons. 
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Those icons may be colored based upon the network elements' performance . The user may 
select the performance metric to be monitored for the network elements. However, claim 1 
requires "modifying the visual network plan . . . according to which hardware and/or software 
exists in the protocol tester ." 

Oliver does not determine, identify or display what hardware or software is on the 
network elements or on a protocol tester. Moreover, Oliver does not modify a network 
display (or visual network plan) based upon the hardware or software on the network 
elements or on a protocol tester. Instead, in Oliver, the network display is modified by 
changing colors based only upon the performance of the network elements. Oliver does not 
even change the colors of the network display based upon the performance of the protocol 
tester. The function and operation of Oliver's performance monitor itself has no effect on the 
network display. 

2. The interpreter element 

Claim 1 further recites: 

an interpreter marks the elements for which a selection exists and/or 
which may be used for the configuration of the telecommunication 
measurement task according to the hardware and/or software of the 
protocol tester. 

The Examiner has cited paragraphs [0054]-[0056] in Oliver as disclosing this element. 
(Examiner's Answer at 4). The Examiner further stated that in Oliver "an interpreter 
(performance monitor interface) is used to mark/select elements and their associated 
performance metrics." Paragraphs [0054]-[0056] are copied below. 

[0054] FIG. 8 depicts a method of monitoring the performance of the 
network according to an embodiment of the present invention. Referring 
to FIG. 8, in step 800, the performance monitor reads and displays the 
network view chosen by the user. In step 805, the performance monitor 
reads the performance queue and in step 810 stores in a buffer 
performance metric information for the network. In step 815, the 
performance monitor determines which metric to display based on input 
from the user or other criteria. The user input may be provided through a 
menuing structure which displays available metrics for the user to choose. 
Alternatively, the polling monitor may cycle through the performance 
metrics one at a time or may be set to a default value for a particular 
network view. 
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[0055] In step 820, the performance monitor displays a color as part 
of an icon associated with a hierarchical object depicted in the network 
view. The hierarchical object may be a network element, link or a subnet 
or network or network elements. When the object is a network element or 
link, the color may be selected based on the selected performance metric 
for that network element. When the object is a subnet or hierarchical 
depiction of multiple network elements or interfaces, the color may be 
chosen to represent the worst case element or interface within the object. 
Any other convenient coloring scheme is contemplated, however, for 
hierarchical objects including averaging the performance metric data for 
network elements or interfaces within the object or depicting the best 
performing element or interface. Combinations of different performance 
metrics are also contemplated to determine the coloring. 

[0056] In step 825, the performance monitor may initiate actions or 
events when any performance metric exceeds a predetermined threshold. 

This is similar to the disclosure cited above. The Oliver reference teaches displaying 
network elements as icons that may be colored based upon the network elements' 
performance . The user may select the performance metric to be monitored for the network 
elements. However, claim 1 requires that the elements be marked "according to the hardware 
and/or software of the protocol tester ." 

As shown by a reading of the cited paragraphs, the Oliver reference fails to teach or 
suggest performing any action - including marking network elements - according to the 
hardware or software of the protocol tester. In Oliver the hardware and software on the 
performance monitor and the polling agent is irrelevant to the network display. Instead, only 
the performance of the network elements (which are not the claimed protocol tester) 
determines how the network will be colored on the display. 

3. The measurement device elements 

Claim 20 recites: 

identifying one or more software application stored on the 
measurement device. 

Claim 21 recites: 

identifying one or more hardware components installed on the 
measurement device. 

The Examiner cited paragraphs [0031] and [0033] in Oliver as disclosing these 
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elements. (Examiner's Answer at 5). The Examiner further stated that 

Oliver teaches defining and configuring software components (e.g., 
polling agents) and hardware components (e.g., master database) to 
implement the monitoring system (see par. [31], [33]). It would have been 
obvious to one skilled in the art that such hardware and software 
components must have been properly identified (i.e., by identifiers, 
addresses, etc.,) by the monitoring system. 

Paragraphs [0031]-[0033] are copied below. 

[0031] The monitoring system 205 may be deployed as a program 
running on a single computer system. Alternatively, the monitoring 
system may be deployed as a program running on one or more distributed 
servers coupled together over a network. The number of polling agents 
220 that are deployed may depend on the number of network elements 
being monitored and the performance of the network. For example, 
Gigabit Ethernet networks may call for more polling agents per network 
element than lower frequency networks such as 10 and 100 Megabit per 
second networks. In general, the number of polling agents is determined 
to permit each polling agent to complete a polling or monitoring cycle in 
less time than that required by a polling or monitoring cycle of the 
network elements or monitors being polled. 

[0033] The controller 200 is coupled to the master database 300. The 
master database 300 is a relational database that stores configuration 
information used to describe the network and all of the elements within it 
that are to be monitored. An illustrative view of the master database 300 
is shown in FIG. 3. Referring to FIG. 3, the master database includes 
configuration tables 310 to 360 that describe the network and configure 
the system. The configuration tables include the network table 310, the 
network nodes table 320, network interfaces table 330, the network 
services table 340, the network metrics table 350 and the network views 
table 360. The tables may be considered individual databases or portions 
of a database and may be consolidated into a single master database or 
distributed among one or more control databases. 

Paragraph [003 1] teaches how to select the number of polling agents. Specifically, 
the number of polling agents should be selected based upon the monitoring cycle of the 
network elements. Oliver does not teach or suggest selecting polling agents based upon the 
software applications or hardware components of the polling agents themselves. 

Paragraph [0033] teaches that a master database is used to store configuration 
information to describe the network and its elements. Oliver does not teach or suggest 
storing information related to the software applications or hardware components of the 
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polling agents themselves. 

The Examiner's remarks appear to equate the claimed software applications (which he 
labels as "software components") to the polling agents and the hardware components to the 
master database. (Examiner's Answer at 5). However, claims 20 and 21 require that the 
software application or hardware components be stored or installed, respectively, on the 
"measurement device." The Examiner has previously identified the performance monitor 
(215) as the claimed "measurement device." The Oliver disclosure makes it clear that the 
polling agents (225) and master database (300) are completely separate and apart from the 
performance monitor (215). (See, FIG. 2). Therefore, even if Oliver taught using existence 
of the polling agents or the master database to identify a measurement task (which it does not 
do), the polling agents and master database are not part of the performance monitor or 
measurement device as required in claims 20 and 2 1 . 

C. Conclusion 

The Oliver reference fails to teach or suggest "modifying the visual network plan," 
"an interpreter," "identifying one or more software application," or "identifying one or more 
hardware components." Therefore, the pending claims are patentable over the Oliver 
application and should be passed to issuance. 

For all the reasons discussed above, the rejections of claims 1, 2, 4 - 10, 12 - 16, 20 
and 21 should be reversed because the claims relate to patentable inventions that are not 
rendered obvious by the Oliver reference. 


FOGARTY, L.L.C. 
3010 LB J Freeway, Suite 1200 
Dallas, Texas 75234 
214-722-8983 (direct) 
214-272-2778 (fax) 


Respectfully submitted, 


November 18. 2009 
Date 


/Michael J. Fogarty. Ill/ 
Michael J. Fogarty, III 
Attorney for Appellant 
Reg. No. 42,541 
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